The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also correspond to disclosed embodiments.
In the computing arts, it is most common to have storage mechanisms which are directly accessed and managed by an Operating System (OS) in conjunction with a Central Processing Unit (CPU), the OS residing upon a computing device and enabled through execution capabilities of the CPU. However, alternative mechanisms also exist, such as DMA (Direct Memory Access) based mechanisms and Direct Access Storage devices which operate independently of a host and its operating system and file systems, for example, enabling access directly to hosted applications executing on the host without requiring that such hosted applications communicate access requests through the host or its operating system and/or file system.
Prior to standard storage interfaces (circa mid 1980s), programmers were required to write code to specifically handle reading and writing data from hard disk drives. Such code was required to identify cylinder, head, track and sector(s) on the hard disk drive (HDD) as part of the read and write operations. Identifying such detail as part of read and write operations to a HDD required changes to an OS in order to support any new HDD, given that the cylinder, head, track and sector(s) were inevitably different than what had been previously supported.
As standard storage interfaces, such as SCSI, ATA, SAS, SATA, FC, etc., were developed and adopted, it was then possible to hide the HDD's underlying cylinder, head, track and sector(s) layout from the programmer and present a consistent interface to the HDD, regardless of its underlying physical structure. These standard storage interfaces thus allowed programmers to simply identify a logical address in a command sent over the standard storage interface and the firmware in the hard disk drive which implemented the standard storage interface would then translate the logical address into the corresponding cylinder, head, track and sector(s) necessary to perform the read and/or write operation, move the read/write head to the correct location on the cylinder etc., and read or write the actual data per the command.
Device drivers to support these standard storage interfaces were included in operating systems so that applications residing on the OS could use standard OS calls to access any HDD via the standard storage interface, regardless of the HDD's underlying physical structure. While the standard storage interfaces and the supporting device drivers within the operating systems provided a solution to the complexities of identifying a HDD's underlying cylinder, head, track and sector(s), the standard storage interfaces and supporting device drivers themselves add complexity as well as computational overhead and therefore inefficiency which can slow performance.
The present state of the art may therefore benefit from the teachings set forth herein.